In the field of the current interfaces, two different trends are apparent.
On the one hand, rich and sophisticated interfaces are being developed that rely on the precise knowledge of the terminal accessing the service. These are so-called “closed” environments. Such is the case, for example, for services or applications dedicated to the iPhone, television offerings based on receivers or boxes which are clearly known, and so on.
This first approach requires, in particular, the users to invest in a full, and often proprietary, solution.
On the other hand, conversely, in a desire to make access to the resources of the Internet universally available, web browsers have emerged. These are so-called “open” environments. So as to be accessible to a very large number of terminals, these browsers have remained highly independent of the capabilities of the terminal, since all that is needed is a pointing device (a mouse, in particular) to use a browser.
This second approach, through its attempt at genericity, is ill suited to the growing diversity of the types of terminals used to access a service, culminating in an under-use of the capabilities of the terminal or, on the other hand, in the failure to recognize its limitations.
Furthermore, this second approach is ill suited to the handicap of certain users.
Also, in addition, it does not take into account usage contexts, in particular the mobility of the terminal, the fact that a conversation is already in progress, etc. Now, these usage contexts could have been indicated by the user or been deduced from the configuration set up by the user on his or her terminal (terminal in “Meeting” mode, microphone deactivated, etc.).
A number of solutions now exist that make it possible to indicate to a terminal to indicate its hardware and software characteristics to a service or an application, such that the latter adapts its content and/or the presentation of its content on the terminal concerned.
In particular, the specifications RFC 2534 and 1999 provide for a terminal to be able to indicate information describing its capabilities concerning the display, printing and reception of faxes. However, because of its age, they are no longer suited to the current complexity of the applications and of the terminals.
In its recommendation CP/PP1.0 dated 15 Jan. 2004, of which version 2.0 is in the working document state, the W3C (World Wide Web Consortium) consortium is drawing up a standard enabling each terminal to describe its capabilities. These are essentially capabilities concerning the hardware, the operating system, the Web browser and, where appropriate, the type of network connectivity. The aim is to enable a Web server to adapt the content delivered and its formatting to the limitations of the terminal. This recommendation draws on the RDF (Resource Description Framework) standard, based on the XML language, to describe the capabilities of a terminal.
The OMA Alliance (Open Mobile Alliance) has adopted the recommendation of the W3C consortium to detail its modalities of use in the context of mobile terminals. These modalities of use essentially specify the use of the composite capabilities/preferences profiles CC/PP on session according to the WAP or WSP protocol (WSP standing for WAP session protocol) and on session according to the wireless http or W-http (standing for WAP Wireless profiled http) protocol in a ratified document entitled User Agent Profile version 2.0.
Now, all these solutions are essentially focused on the passive playback capabilities of the terminals such as the display possibilities, the presence of loudspeakers, etc., and partially on its capabilities to send information (texts, voice, etc.). In all these cases, the single and unique objective of such information is to enable the Web server to adapt the delivered content (Content Adaptation). This content adaptation is then performed either by the selection of a content having a suitable format (the same content being available in several formats), or by formatting of the content in a different manner according to the playback and/or sending capabilities indicated, or by transforming the content (notably by reducing resolution, transcoding, etc.).
The interactions of the terminal with the service remain limited either, in the first approach, to the one proposed by the proprietary interface solution with its drawbacks or, in the second approach, to the generic interactions.
In this second approach, the potentialities of the terminal are therefore not fully exploited because this approach levels down the interactions between the terminal and the services, leading to the underuse of the interaction capabilities of the terminal.